Persistent data and session control are the abilities of a system to recover session status and data that were “in flight” when a system failure occurs. Session connection and data can be subject to loss due to failures in equipment, software, telecommunication, or other components of the system. For example, if a user is in the middle of a transaction when an interruption in the data source occurs, a database that the user was working in could be left in an ambiguous state. Similarly, when a user loses its connection with a session, the user may not be able to reconnect to the session and data source at the same point it was at before the connection was lost. Systems that can benefit from persistent session and data control include computing systems, software systems, and telecommunication systems.
One issue addressed by persistent data control is the reconnection of users with data. A number of schemes have been developed to address this situation by various manufacturers. Hardware data mirroring is an example of a hardware approach that is used for database recovery. Data mirroring is accomplished by writing each data segment twice on the direct access storage device. The mirroring function can be controlled by either the operating system or the hardware itself depending upon the manufacturer. Mirroring can also be accomplished by using a software approach using software either in the operating system or in the middleware to implement the mirroring function.
There are several drawbacks to these approaches. These techniques can be dependent upon proprietary hardware or proprietary software to ensure that the data is properly copied. For example, direct access storage devices need to be designed specifically to accomplish the data mirroring in the hardware approach. Moreover, because these techniques typically use local storage clusters to perform the backup, in the event of a disaster in the local storage clusters, both the primary data and the copy of the primary data can be lost.
Another technique that has been used to implement persistent data is the use of a single primary controller backed up by a single alternative controller. To implement this method, the system administrator predefines primary and alternate data areas. When the primary controller is brought back into service after the interruption, the data control is switched from the alternative controller back to the primary controller. With this method, it is usually not possible to add a primary controller of an arbitrary disk device type to the hardware cluster mix. Further, when the primary controller is brought back online, it typically has to be attached to the same system where the failure occurred at the same location as the original primary controller.
The Internet has created a second problem for persistent session and data control relating to persistency. Because the HTTP protocol consists of one transmission followed by one response, many data clusters may be involved in each transaction. In the case of a session interruption, it can be unclear which controller needs recovery.
Current data persistent approaches often require proprietary hardware to implement persistency solutions. In these approaches, the system typically has to originate from a particular manufacturer using the correct hardware and the most current operating system for it to properly implement data persistency.
Another limitation in current persistency systems is the equipment and software upon which the persistency is built. Most hardware solutions use data controllers that connect data access storage devices through a limited number of pathways to the hardware channel. Since the number of paths to each device is typically limited to four pathways, only two processors can be connected to each primary/alternate pair of storage devices.
In additional, the fundamental architecture that underlay historical systems were typically designed to accommodate monolithic structuring of applications, such as functional decomposition applications.